-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate from Butterknife to View bindings #115
base: master
Are you sure you want to change the base?
Conversation
@@ -585,30 +575,14 @@ public void onClick(View v) { | |||
|
|||
|
|||
class AccountViewHolder extends RecyclerView.ViewHolder implements PopupMenu.OnMenuItemClickListener { | |||
@BindView(R.id.primary_text) | |||
TextView accountName; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
final TextView accountName = binding.listItem.primaryText;
@BindView(R.id.input_budget_amount) | ||
CalculatorEditText amountEditText; | ||
@BindView(R.id.btn_remove_item) | ||
ImageView removeItemBtn; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
final ImageView removeItemBtn = binding.btnRemoveItem;
public View inflateView(LayoutInflater inflater, ViewGroup container) { | ||
mBinding = FragmentBarChartBinding.inflate(inflater, container, false); | ||
return mBinding.getRoot(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mChart = mBinding.barChart;
@pnemonic78 for the remaining changes, I'm not sure what you're requesting. Do you want to add a field to store some of the references to the views in the view binding for some reason? |
Yes. Keep the member fields, but instead of having ButterKnife assign them from the view, your assign them from the binding. |
Understood. I'm going to disagree with your suggestion here: I don't think this improves code readability. For example, to me Furthermore, in Android Studio you can use "Go To -> Implementation" to jump directly to the layout editor. Re-aliasing the view makes this a two-step process. If in some cases the name of the binding is not clear, I would argue that the ID of the corresponding view should be renamed, instead of creating a local alias in code. |
Definitely names in the XML should be better. |
Previously, BaseDrawerActivity only needed the layout ID to be provided from the subclass. Now the subclass will be responsible for inflating its view, which can be done either with or without view bindings. In addition, use findViewById instead of Butterknife.
Is it ready or not? |
I'm currently using the build off this branch, and it works fine, although I cannot guarantee that I've tested all the possible corner cases.
The changes are mostly mechanical, however in some cases (e.g. BaseDrawerActivity and BaseReportFragment) there were changes introduced in how subclasses interact with the base class.
Fixes #73